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Abstract 


Generic programming is a paradigm whose wide adop- 
tion by the C++ community is quite recent. In this 
scheme most classes and procedures are parameterized, 
leading to the construction of general and efficient soft- 
ware components. In this paper, we show how some de- 
sign patterns from Gamma et al. can be adapted to this 
paradigm. Although these patterns rely highly on dy- 
namic binding, we show that, by intensive use of para- 
metric polymorphism, the method calls in these patterns 
can be resolved at compile- time. In intensive computa- 
tions, the generic patterns bring a significant speed-up 
compared to their classical peers. 


1 Introduction 


This work has its origin in the development of Olena 
[11], our image processing library. When designing a li- 
brary, one wants to implement algorithms that work on 
a wide variety of types without having to write a pro- 
cedure for each concrete type. In short, one algorithm 
should be generic enough to map to a single procedure. 
In object-oriented programming this is achieved using 
abstract types. Design Patterns , which are design struc- 
tures that have often proved to be useful in scientific 
computing, rely even more on abstract types and inclu- 
sion polymorphism 1 . 

However, when it comes to numerical computing, 
object-oriented designs can lead to a huge performance 
loss, especially as there may be a high number of virtual 
functions calls [7] required to perform operations over 

1 Inclusion polymorphism corresponds to virtual member functions 
in C++, deferred functions in Eiffel, and primitive functions in Ada. 


an abstraction. Yet, rejecting design patterns for the sake 
of efficiency seems radical. 

In this paper, we show that some design patterns from 
Gamma et al. [10] can be adapted to generic program- 
ming. To this aim, virtual functions calls are avoided by 
replacing inclusion polymorphism by parametric poly- 
morphism. 

This paper presents patterns in C++, but, although they 
won’t map directly to other languages because “gener- 
icity” differs from language to language, our work does 
not apply only to C++: our main focus is to devise flex- 
ible designs in contexts where efficiency is critical. In 
addition, C++ being a multi-paradigm programming lan- 
guage [28], the techniques described here can be limited 
to critical parts of the code dedicated to intensive com- 
putation. 

In section 2 we introduce generic programming and 
present its advantages over classical object-oriented pro- 
gramming. Then, section 3 presents and discusses the 
design of the following patterns: Generic Bridge, 
Generic Iterator, Generic Abstract Factory, 
Generic Template Method, Generic Decora- 
tor, and Generic Visitor. We conclude and con- 
sider the perspectives of our work in section 4. 


2 Generic programming 


By “generic programming” we refer to a use of parame- 
terization which goes beyond simple genericity on data 
types. Generic programming is an abstract and efficient 
way of designing and assembling components [15] and 
interfacing them with algorithms. 


Generic programming is an attractive paradigm for sci- 
entific numerical components [12] and numerous li- 
braries are available on the Internet [22] for various do- 
mains: containers, graphs, linear algebra, computational 
geometry, differential equations, neural networks, visu- 
alization, image processing, etc. 

The most famous generic library is probably the Stan- 
dard Template Library [26], In fact, generic program- 
ming appeared with the adoption of STL by the C++ 
standardization committee and was made possible with 
the addition of new generic capabilities to this lan- 
guage [27, 21]. 

Several generic programming idioms have already been 
discovered and many are listed in [30]. Most generic 
libraries use the Generic Iterator that we describe 
in 3.2. In POOMA [12] — a scientific fr a mework 
for multi-dimensional arrays, fields, particles, and trans- 
forms — the Generic Envelope-Letter pattern ap- 
pears. In the Requested Interface pattern [16], a 
Generic Bridge is introduced to handle efficiently an 
adaptation layer which mediates between the interfaces 
of the servers and of the clients. 


2.1 Efficiency 


The way abstractions are handled in the object-oriented 
programming paradigm ruins the performances, espe- 
cially when the overhead implied by the abstract inter- 
face used to access the data is significant in comparison 
with the time needed to process the data. 

For example, in an image processing library in which 
algorithms can work on many kinds of aggregates (two 
or three dimensional images, graphs, etc.), a procedure 
that adds a constant to an aggregate may be written using 
the object-oriented programming paradigm as follows. 


tempiate< class i > 

void add (aggregate<T>& input, T value) 

{ 

iterator<T>& iter = input. createiterator (); 
for (iter. first () ; liter. is doneO ; iter.next(J) 
iter.current_item () += value; 

} 


Here, aggregate<T> and iterator<T> are abstract 
classes to support the numerous aggregates available: 
parameterization is used to achieve genericity on pixel 
types, and object-oriented abstractions are used to get 
genericity on the image structure. 



dedicated C 

classical C++ 

generic C++ 

add 

10.7s 

37.7s 

12.4s 

mean 

47.3s 

225.8s 

57.5s 


Table 1: Timing of algorithms written in different 
paradigms. (The code was compiled with gcc 2.95.2 
and timed on an AMD K6-2 380MHz machine running 
GNU/Linux.) 

As a consequence, for each iteration the direct call to 
T : :operator+=() is drowned in the virtual calls to 
current_item( ), next() and isdone (), leading to 
poor performances. 

Table 1 compares classical object-oriented programming 
and generic programming and shows a speed-up factor 
of 3 to 4. The add test consists in the addition of a 
constant value to each element of an aggregate. The 
mean test replaces each element of an aggregate by the 
mean of its four neighbors. The durations correspond 
to 200 calls to these tests on a two dimensional image 
of 1024 x 1024 integers. “Dedicated C” corresponds to 
handwritten C specifically tuned for 2D images of inte- 
gers, so the difference with classical C++ is what people 
call the abstraction penalty. While this is not a text- 
book case — we do have such algorithms in Olena — it 
is true that usually the impact of object-oriented abstrac- 
tion is insignificant. High speed-ups are obtained from 
generic programming compared to object-oriented pro- 
gramming when data processing is cheap relatively to 
data access. For example for simple list iteration or ma- 
trix multiplication. 

The generic programming writing of this algorithm, us- 
ing a Generic Iterator, will be given in section 3.2. 


2.2 Generic programming from the language 
point of view 


Generic programming relies on the use of several pro- 
gramming language features, some of which being de- 
scribed below. 


Genericity is the main way of generalizing object- 
oriented code. Not all languages support both 
generic classes and generic procedures (e.g., Eiffel 
features only generic classes). 

Nested type names refers to the ability to look up a 
type as member of a class and allow to link re- 
lated types (such as image2d and iterator2d) 


together. 

Constrained genericity is a way to restrict the possible 
values of formal parameters using signatures (e.g., 
when using ML functors [19]) or constraining a 
type to be a subclass of another (as in Eiffel or Ada 
95). C++ does not provide specific language fea- 
tures to support constrained genericity, but subclass 
constraints [29, 23] or feature requirements [18, 25] 
can be expressed using other available language fa- 
cilities [27], 

Generic specialization allows the specialization of an 
algorithm (e.g., dedicated to a particular data type) 
overriding the generic implementation. 

Not all languages support these features, this explains 
why the patterns we present in C++ won’t apply directly 
to other languages. 


2.3 Generic programming guidelines 


From our experience in building Olena, which is entirely 
carried out by generic programming, we derived the fol- 
lowing guidelines. These rules may seem drastic, but 
their appliance can be limited to critical parts of the code 
dedicated to intensive computation. 

Guidelines for generic classes: 

• Avoid inclusion polymorphism. 

In other words, the type of a variable (static type, 
known at compile-time) is exactly that of the in- 
stance it holds (dynamic type, known at run-time). 
The main requirement of generic programming is 
that the concrete type of every object is known at 
compile-time. 

• Avoid operation polymorphism. 

Abstract methods are forbidden', dynamic binding 
is too expensive. Simulate operation polymorphism 
with either: (i) parametric classes thanks to the Cu- 
riously Recurring Template idiom (see section 3.4), 
or (ii) parametric methods, which lead to a form of 
ad-hoc polymorphism (overloading). 

• Use inheritance only to factor methods and to de- 
clare attributes shared by several subclasses. 

Guidelines for procedures which use generic pat- 
terns: 


• Parameterize the procedures by the types of their 
inputs, even if the input itself is parameterized. 

• Parameterize the procedures by the types of the 
components used (unless they can be obtained by 
a nested type lookup in another parameter- type). 


3 Generic Design Patterns 


Our generic design patterns exposition is Gamma et al. ’s 
description of the original, abstract version of the pat- 
terns [10]. We do not repeat the elements that can be 
found in this book. 


3.1 Generic Bridge 


Intent 

Decouple an abstraction from its implementation so that 
the two can vary independently. 


Structure 



Participants 

An abstraction class is parameterized by the 
Implementation used. Any (low-level) operation on 
the abstraction is delegated to the implementation in- 
stance. 


Consequences 

Because the implementation is statically bound to the 
abstraction, you can’t switch implementation at run- 
time. This kind of restriction is common to generic pro- 
gramming: configurations must be known at compile- 
time. 


Known Uses 

This pattern is really straightforward and broadly used 
in generic libraries. For example the allocator pa- 
rameter in STL containers is an instance of GENERIC 
Bridge. 

The pooma team [5] use the term engine to name im- 
plementation classes that defines the way matrices are 
stored in memory. This is also a Generic Bridge. 

The Ada 95 rational [14, section 12.6] gives an example 
of Generic Bridge: a generic empty package (also 
called signature) is used to allow multiple implementa- 
tion of an abstraction (here, a mapping). 

As in the case of the original patterns, the structure of 
this pattern is the same as the Generic Strategy pat- 
tern. These patterns share the same implementation. 


3.2 Generic Iterator 


Intent 

To provide an efficient way to access the elements of 
an aggregate without exposing its underlying represen- 
tation. 


Motivation 

In numeric computing, data are often aggregates and al- 
gorithms usually need to work on several types of ag- 
gregate. Since there should be only one implementation 
of each algorithm, procedures must accept aggregates of 
various types as input and be able to browse their el- 
ements in some unified way; iterators are thus a very 
common tool. As an extra requirement compared to the 
original pattern, iterations must be efficient. 


Structure 



We use typedef as a non-standard extension of 
uml [24] to represent type aliases in classes. 


Participants 

The term concept was coined by M. H. Austern [1], to 
name a set of requirements on a type in stl. A type 
which satisfies these requirements is a model of this con- 
cept. The notion of concept replaces the classical object- 
oriented notion of abstract class. 

For this pattern, two concepts are defined: aggregate and 
iterator , and two concrete classes model these concepts. 


Consequences 

Since no operation is polymorphic, iterating over an ag- 
gregate is more efficient while still being generic. More- 
over, the compiler can now perform additional optimiza- 
tions such as inlining, loop unrolling and instruction 
scheduling, that virtual function calls hindered. 

Efficiency is a serious advantage. However we lose the 
dynamic behavior of the original pattern. For example 
we cannot iterate over a tree whose cells do not have the 
same type 2 . 


2 A link between an abstract aggregate and the corresponding 
generic procedures can be achieved using lazy compilation and dy- 
namic loading of generic code [8]. 


Implementation 

Although a concept is denoted in uml by the stereotype 
<<type>>, in C++ it does not lead to a type: a con- 
cept only exists in the documentation. Indeed the fact 
that concepts have no mapping in the C++ syntax makes 
early detection of programming errors difficult. Sev- 
eral tricks have been proposed to address this issue by 
explicitly checking that the arguments of an algorithm 
are models of the expected concepts [18, 25]. In Ada 
95, concept requirements (types, functions, procedures) 
can be captured by the formal parameters of an empty 
generic package (the signature idiom) [9]. 

For the user, a type-parameter (such as Aggregate_ 
Model in the sample code) represents a model of aggre- 
gate and the corresponding model of iterator can then 
be deduced statically. 


Sample Code 

tempiate< class i > 
class buffer 
{ 

typedef T datatype; 

typedef buf fer_iterator<T> iteratortype; 
// ... 

}; 


tempiate< class Aggregate model > 
void add(Aggregate_Model& input, 

typename Aggregate_Model: :data_type value] 

{ 

typename Aggregate_Model : : iterator_type& 
iter = input. createiterator (); 

for (iter.firstO ; ! iter. is donet ) ; iter.nextO) 
iter. currentitem () += value; 


Known Uses 


Most generic libraries, such as STL, use the Generic 
Iterator. 


Variations 

We translated the Gamma et al. version, with methods 
first (), is_done( ), and next ( ) in the iterator class. 
STL uses another approach where pointers should also 


be models of iterators: as a consequence, iterators can- 
not have methods and most of their operators will rely 
on methods of the container’s class. This makes imple- 
mentation of multiple schemes of iteration difficult: for 
example compare a forward and a backward iteration in 
STL: 


container: :iterator i; 
for (i = c.begin(); i != c.end(); ++i) 
// ... 

container: : reverseiterator i; 
for (i = c.rbegin(); i != c.rendO; ++i] 
II ... 


First, the syntax differs. From the STL point of view 
this is not a serious issue, because iterators are meant to 
be passed to algorithms as instances. For a wider use, 
however, this prevents parametric selection of the itera- 
tor (i.e., passing the iterator as a type). Second, you have 
to implement as many xbegin ( ) and xend ( ) methods 
as there are schemes of iteration, leading to a higher cou- 
pling [17] between iterators and containers. 


Another idea consists in the removal of all the itera- 
tor related definitions, such as c reate ite rato r ( ) or 
iterator type, from concrete_aggregate<T> in 
order to allow the addition of new iterators without mod- 
ifying the existing aggregate classes [32], This can be 
achieved using traits classes [20] to associate iteration 
schemes with aggregates: the iterated aggregate instance 
is given as an argument to the iterator constructor. For 
example we would rewrite the add ( ) function as fol- 
lows. 


tempiate< class Aggregatemoaei > 
void add(Aggregate_Model& input, 

typename Aggregate_Model: :data_type value) 

{ 

typename forward_iterator< AggregateModel >::type 
iter (input); 

for (iter.firstO; !iter.is_done() ; iter.nextO) 
iter. currentitem () += value; 

} 


This eliminates the need to declare iterators into the ag- 
gregate class, and allows further additions of iteration 
schemes by the simple means of creating a new traits 
class (for example backward_iterator<T>). 


3.3 Generic Abstract Factory 


Structure 


Intent 


To create families of related or dependent objects. 


Motivation 

Let us go back over the different iteration schemes prob- 
lem discussed previously. We want to define several kind 
of iterators for an aggregate, and as so we are candidates 
for the Abstract Factory pattern. The STL example 
can be rewritten as follows to make this pattern explicit: 
iterators are products, built by an aggregate which can 
be seen as a factory. 


ractory_a: :proauct_i 1 ; 
for (i = c.beginf); i != c.endO; ++i) 
II ... 

factorya: :product_2 i; 
for (i = c.rbeginO; i != c.rendO; ++i] 
II ... 


Implementing a GENERIC ABSTRACT FACTORY is 
therefore just a matter of defining the product types in 
the classes that should be used as a factory. This is really 
simpler than the original pattern. Yet there is one sig- 
nificant difference in usage: an Abstract Factory 
returns an object whereas a Generic Abstract Fac- 
tory returns a type, giving more flexibility (e.g. con- 
structors can be overloaded). 

We have shown that if we want to implement multi- 
ple iteration schemes, it is better to use traits classes, 
to define the schemes out of the container. A trait 
class if a Generic Abstract Factory too (think of 
trait: :type as factory: :product). But one issue 
is that these two techniques are not homogeneous. Say 
we want to add a new iterator to the STL containers: we 
cannot change the container classes, therefore we define 
our new iterator in a traits, but now we must use a differ- 
ent syntax whether we use one iterator or the other. 

The structure we present here takes care of this: both in- 
ternal and external definitions of products can be made, 
but the user will always use the same syntax. 



Here, we represent a parametric method by boxing its 
parameter. For instance, Factory is a type-parameter of 
the method Accept. This does cannot conform to uml 
since uml lacks support for parametric methods. 


Participants 

We have two factories, named concretefactoryl 
and concrete_factory_2 which each defines two 
products: productatype and product b type. 
The first factory define the products intrusively (in it’s 
own class), while the second do it externally (in the prod- 
uct’s traits). 

To unify the utilization, the traits default is to use the 
type that might be defined in the “factory” class. For 
example the type a defined in foo<Factory>, defined 
as product_a_trait<Factory> : :type will equal 
to concretefactoryl : : productatype in the 
case Factory is concrete factory l. 


Consequences 

Contrary to the pattern of Gamma, inheritance is no 
longer needed, neither for factories, nor for products. In- 
troducing a new product merely requires adding a new 





parametrized structure to handle the types aliases (e.g., 
productctraits), and to specialize this structure 
when the alias p roduct c type is not provided by the 
factory. 


Known Uses 


Many uses of this pattern can be found in stl. For ex- 
ample all the containers whose contents can be browsed 
forwards or backwards 3 define two products: forward 
and backward iterators. 

The actual type of a list iterator never explicitly appears 
in client code, as for any class name of concrete prod- 
ucts. Rather, the user refers to A: : iterator, and A is 
an stl container used as a concrete factory. 


3.4 Generic Template Method 


Intent 


To define the canvas of an efficient algorithm in a supe- 
rior class, deferring some steps to subclasses. 


Motivation 


In generic programming, we limit inheritance to factor 
methods [section 2.3]; here, we want a superior class 
to define an operation some parts of which (primitive 
operations) are defined only in inferior classes. As usual 
we want calls to the primitive operations, as well as calls 
to the template method, to be resolved at compile-time. 


3 vectors, doubly linked lists and dequeues are models of this con- 
cept, named reversible containers 


Structure 



static_cast<T&>(*this). primitive^ _impl(); 


abstract_class<concrete_class> 

A 


concrete_class 

primitive^ _impl() 
primitive_2_impl() 


Participants 

In the object-oriented paradigm, the selection of the tar- 
get function in a polymorphic operation can be seen as 
a search for the function, browsing the inheritance tree 
upwards from the dynamic type of the object. In prac- 
tice, this is done at run-time by looking up the target in 
a table of function pointers. 

In generic programming, we want that selection to be 
solved at compile-time. In other words, each caller 
should statically know the dynamic type of the object 
from which it calls methods. In the case of a supe- 
rior class calling a method defined in a child class, the 
knowledge of the dynamic type can be given as a tem- 
plate parameter to the superior class. Therefore, any 
class needing to know its dynamic type will be parame- 
terized by its leaf type. 

The parametric class abst ract class defines two op- 
erations: primitive].]) and primitive_2(). Call- 
ing one of these operations leads to casting the target 
object into its dynamic type. The methods executed are 
the implementations of these operations, primitive_ 
l_impl() and primitive_2_impl ( ) . Because the 
object was cast into its leaf type, these functions are 
searched for in the object hierarchy from the leaf type 
up as desired. 


When the programmer later defines the class 
concreteclass with the primitive operation 
implementations, the method templatemethod ( ) is 
inherited and a call to this method leads to the execution 
of the proper implementations. 


Consequences 

In generic programming, operation polymorphism can 
be simulated by “parametric polymorphism through in- 
heritance” and then be solved statically. The cost of dy- 
namic binding is avoided; moreover, the compiler is able 
to inline all the code, including the template method it- 
self. Hence, this design is more efficient. 


Implementation 

The methods primitive_l( ) andprimitive_2() do 
not contain their implementation but a call to an imple- 
mentation; they can be considered as abstract methods. 
Please note that they can also be called by the client 
without knowing that some dispatch is performed. 

This design is made possible by the typing model used 
for C++ template parameters. A C++ compiler has to 
delay its semantic analysis of a template function un- 
til the function is instantiated. The compiler will there- 
fore accept the call to T : : primitive l impl ( ) with- 
out knowing anything about T and will check the pres- 
ence of this method later when the call to the A<T> : : 
primitive_l( ) is actually performed, if it ever is. In 
Ada [13], on the contrary, such postponed type checking 
does not exist, for a function shall type check even if it is 
not instantiated. This pattern is therefore not applicable 
as is in this language. 

One disadvantage of this pattern over Gamma’s imple- 
mentation is directly related to this: the compiler won’t 
check the actual presence of the implementations in the 
subclasses. While a C++ compiler will warn you if you 
do not supply an implementation for an abstract func- 
tion, even if it is not used, that same compiler will be 
quiet if pseudo-virtual operations like primitive_l_ 
impl ( ) are not defined and not used. Special care must 
thus be taken when building libraries not to forget such 
functions since the error won’t come to light until the 
function is actually used. 

We purposely added the suffixes impl to the name of 
primitives to distinguish the implementation functions. 


One could image that the implementation would use the 
same name as the primitive, but this require some addi- 
tional care as the abstract primitive can call itself recur- 
sively when the implementation is absent. 4 


Sample Code 


The following code shows how to define a getnext ( ) 
operation in each iterator of a library of containers. Ob- 
viously, get next ( ) is a template method made by 
issuing successive calls to the current_item( ) and 
next ( ) methods of the actual iterator. 


We define this method in a superclass iterator_ 
common parametrized by its subtype, and have all iter- 
ators derive from this class. 


tempiate< class cnna, Class vaiue iype > 
class iterato r_common 
{ 

public : 

Value_Type& getnext () { 

// template method 
Value_Type& v = currentitem (); 

I return v, 

Value_Type& currentitem () { 

// call the actual implementation 
static_cast<Child&>(*this) . current_item_impl() ; 

I 

void next ( ) { 

// call the actual implementation 
static_cast<Child&> ( *this ) . nextimpl ( ) ; 

I 


// sample iterator aetimtion 
template< class ValueType > 
class bufferiterator: public 

iterator_common< buffer_iterator< Value_Type >, 
ValueType > 

{ 

public: 

Value_Type current_item_impl () { ... }; 
void nextimpl () { ... }; 
void first ( ) { ... } ; 
void isdone () { ... }; 

II ... 

}; 


Known Uses 


This pattern relies on an idiom called Curiously Recur- 
ring Template [4] derived from the Barton and Nachman 


4 You can ensure at compile-time that two functions (the primitive 
and its implementation) are different by passing their addresses to a 
helper template specialized in the case its two arguments are equal. 


Trick [2], In [2] this idiom is used to define a binary op- 
erator (for instance +) in a superior class from the corre- 
sponding unary operator (here +=) defined in an inferior 
class. Further examples are given in [30]. 


3.5 Generic Decorator 


Intent 


To efficiently define additional responsibilities to a set of 
objects or to replace functionalities of a set of objects, 
by means of subclassing. 


Consequences 

This pattern has two advantages over Gamma’s. First, 
any method that is not modified by the decorator is auto- 
matically inherited. While Gamma’s version uses com- 
position and must therefore delegate each unmodified 
operation. Second, decoration can be applied to a set 
of classes that are not related via inheritance. Therefore, 
a decorator becomes truly generic. 

On the other hand we lose the capability of dynamically 
adding a decoration to an object. 


Sample Code 


Structure 




Decorating an iterator of STL is useful when a container 
holds structured data, and one wants to perform opera- 
tions only on a field of these data. In order to access 
this field, the decorator redefines the data access opera- 
tor ope rato r* ( ) of the iterator. 


// a oasic rea-green-DLue struct 

template< class T > 
struct rgb 
{ 

typedef T redtype; 
redtype red; 

typedef T greentype; 
greentype green; 

typedef T bluetype; 
bluetype blue; 

}; 



We use a special idiom: having a parametric class that 
derives from one of its parameters. This is also known 
as mixin inheritance 5 [3], 


Participants 

A class cone ret e component which can be dec- 
orated, offers an operation operation(). Two 
parametric decorators, cone retedeco rato r_a and 
concrete decorator b, whose parameter is the dec- 
orated type, override this operation. 


5 Mixins are often used in Ada to simulate multiple inheri- 
tance [14], 


// An accessor aass tor tne rea tieia. 

template< class T > 
class getred 
{ 

typedef T inputtype; 

typedef typename T : : redtype outputtype; 

static output_type& 
get (input_type& v) { 
return v. red; 

} 

static const output_type& 
get (const input_type& v) { 
return v. red; 

} 


Note how the rgb<T> structure exposes the type of 
each attribute. This makes cooperation between ob- 
jects easier: here the get red accessor will look up the 
red type type member and doesn’t have to know that 
fields of rgb<T> are of type T. get red can therefore 


Known Uses 


apply to any type that features red and redtype, it is 
not limited to rgb<T>. 


// a decorator tor any iterator 
template< class Decorated, 

template< class > class Access > 
class fieldaccess: public Decorated 
{ 

typedef typename Decorated: :value_type valuetype; 
typedef Access< valuetype > accessor; 

typedef typename accessor: : outputtype outputtype 

fieldaccess () : Decorated () {} 

fieldaccess (const Decorated^ d) : Decorated (d) 

// Overload operator*, use the given accessor 
// to get the proper field. 
output_type& operator* () { 

return accessor: :get (Decorated: : operator* ()); 

} 

const output_type& operator* () const { 

return accessor: :get (Decorated: : operator* ()); 

} 


f ieldaccess is a decorator whose parameters are the 
types of the decorated iterator, and of a helper class 
which specifies the field to be accessed. Actually, this 
second parameter is an example of the Generic Strat- 
egy pattern [6, 30], 


Parameterized inheritance is also called mixin inheri- 
tance and is one way to simulate multiple inheritance 
in Ada 95 [14], This can also be used as an alternate 
way for providing template methods [6] . 


3.6 Generic Visitor 


Intent 

{} 

To define a new operation for the concrete classes of 
hierarchy without modifying the hierarchy. 


Motivation 

In the case of the Visitor pattern, the operation varies 
with the type of the operation target. Since we assume 
to know the exact type as compile-time, a trivial design 
is thus to define this operation as a procedure overloaded 
for each target. Such a design, however, does not have 
the advantages of the translation of the Visitor pattern 
proposed in the next section. 


int main U 

typedef std::list< rgb< int > > A; 

A input; 

// ... initialize the input list ... 

// Build decorated iterators. 
field_access< A: iterator, get red > 
begin = input. begin (), 
end = input. end () ; 

// Assign 10 to each red field. 
std: :fill (begin, end, 10); 


The std : : fill ( ) procedure is a standard STL algo- 
rithm which assigns a value to each element of a range 
(specified by two iterators). Since std : : fill ( ) is here 
given decorated iterators it will only assign red fields to 
10. 


Structure 





Participants 



Note that the decorator is independent of the deco- 
rated iterator: it can apply to any stl iterator, not only 
list<T> :: iterator. The std :: fill ( ) algorithm 
will use methods of f ield access inherited from the 
decorated iterator, such as the assignment, comparison, 
and pre-increment operators. 


In the original Gamma’s pattern the method accept has 
to be defined in each element. The code of each of 
these accept method can be the same 6 , only type of the 

6 This is not actually the case in Gamma’s book, because the name 
of the visiting method to call is dependent on the element type; how- 


this pointer changes. Here we use the same trick as the 
Generic Template Method to factor accept in the 
superclass. 

Each visitor defines a method visit, for each ele- 
ment type that it must handle, visit can be either an 
overloaded function (as in concretevisitorl) or 
a function template (as in concrete_visitor_2). In 
both case, the overload resolution or function instanti- 
ation is made possible by the exact knowledge of the 
element type. 

One advantage of using a member template (as in 
concrete_visitor_2), over an overloaded function 
(as in concrete visitor l) is that the concrete_ 
visitor_2 class does need to be changed when new 
type are added: the visitor can be specialized externally 
should the default be inadequate. 


Consequences 

The code is much closer to the one of Gamma than the 
trivial design presented before, because the visitor is 
here an object with all its advantages (state, life dura- 
tion). 

While accept and visit does not return anything 
in the original pattern, they can be taught to. It the 
Generic Iterator they can even return a type de- 
pendent on the visitor’s type. As the following example 
shows. 


Sample Code 

Let’s consider an image2d class the pixels of which 
should be addressable using different kind of positions 
(Cartesian or polar coordinates, etc.). For better modu- 
larity, we don’t want the image2d to known all position 
types. Therefore we see positions as visitors, which the 
image accepts, accept returns the pixel value corre- 
sponding to the supplied position. The image will pro- 
vide only one access method, and it is up to the visitor to 
perform necessary conversion (e.g. polar to Cartesian) 
to use this interface. 

A position may also refer to a particular channel in a 
color image. The accept return type is thus dependent 
on the visitor. We will use a traits to handle this. 

ever, using the same name (Visit) for all these methods make no 
problem in any language as C++ which support function overloading. 


Tempiate< class visitor, class visited > 
struct visit return trait; 


For each pair (Visitor, Visited) visit_return_ 
traitcVisitor, Visited> : :type is the return type 
of access and visit. 


// racror tne aetimtion or accept tor au images 

template < class Child > 
class image { 
public : 

template < typename Visitor > 

typename visit_return_trait< Visitor, Child >:: 

type accept (Visitor^ v) { 

return v. visit (static_cast< Child& > (*this)); 

} 

II... likewise for const accept 


tempiate< typename i > 

class image_2d : public image< image_2d< T > > { 

public : 

typedef T pixeltype; 

II ... 

T& getvalue (int row, int col ){...> 

const T& getvalue const (int row, int col){...} 

}; 


Here is one possible visitor, with it’s corresponding 
visit retu rn_t rait specialization. 


dass point za i 

public : 

point_2d (int row, int col) { ... } 

template < typename Visited > 
typename Visited: :pixel_type& 
visit (Visited& v) { 

return v.getvalue (row, col); 

} 

II ... 

>;i 

template< class Visited > 

struct visit_return_trait< point_2d, Visited > f 
typedef typename Visited: :pixel_type type; 


channel_point_2d is another visitor, which must be 
parametered to access a particular layer (as in the deco- 
rator example). 



tempiate< tempiate< class > class Access > 
class channel_point_2d { 

public : 

channel_point_2d (int row, int col) { . . . } 

template < typename Visited > 

typename Access< typename Visited :: pixeltype >:: 

output_type& visit (Visited& v) { 

return Access< typename Visited :: pixeltype >:: 
get (v.getvalue (row, col)); 


}; 

template< template< class > class Access, 
class Visited > 
struct visit return trait 
< channel_point_2d< Access >, Visited > { 
typedef typename 

Access< typename Visited :: pixeltype >:: 
outputtype type; 


Finally, the following hypothetical main shows how the 
return value of accept differ according to the visitor 
used. 


image_2d< rgb< int > > img; 
point_2d p ( 1 , 2); 

channel_point_2d<get_red> q ( 3 , 4); 

int v = img. accept (p) ; 
rgb<int> w = img. accept (q); 

} 


In our library, accept and visit are both named 
operator [] so we can write img[p] or p[img] at 
will. 


4 Conclusion and Perspectives 


Based on object programming, generic programming al- 
lows to build and assemble reusable components [15] 
and proved to be useful where efficiency is required. 


Since generic programming (or more generally Gener- 
ative programming [31, 6]) is becoming more popular 
and because much experience and knowledge have been 
accumulated and assimilated in structuring the object- 
oriented programming, we believe that it is time to ex- 
plore the benefits that the former can derive from well- 
proven designs in the latter. 


We showed how design patterns can be adapted to the 
generic programming context by presenting the generic 
versions of three fundamental patterns from Gamma et 
al. [10]: the Generic Bridge, Generic Iterator, 


the Generic Abstract Factory, the Generic 
Template Method, the Generic Decorator, and 
the Generic Visitor. We hope that such work can 
provide some valuable insight, and aid design larger sys- 
tems using generic programming. 
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